It looks like we are actually forcing the unversioned name to be used at another place:

Yes, I checked that removing it produces libLLVM.dylib and libLLVM-.dylib, and ./x build did not fail. So it seems it worked.
However, ZuseZ4 and I discussed that we should prepare both versioned and unversioned libLLVM by COPYING first, not symlink.

Two biggest reasons are

1. Multiple people said that copying libLLVM with the versioned name worked: ./x build failed with llvm-config: error: libLLVM-22-rust-1.96.0-nightly.dylib is missing #154408 (comment)
2. Nokel81 said that symlink did not work for him: ./x build failed with llvm-config: error: libLLVM-22-rust-1.96.0-nightly.dylib is missing #154408 (comment)

for 2, ln -s command that Nokel81 posted on the comment has a typo in the extension part. But we have no idea whether the symlink itself actually failed or whether the command was just pasted incorrectly. It's possible that my method for verifying symlinks is incorrect.

So, we get to land copying PR first, then this symlink later on.

So, we get to land copying PR first, then this symlink later on.

With my suggestion there wouldn't be any symlink either, right? It would just be removing the special case for macOS such that everything is handled the same way as it is handled on Linux.

mmm...symlink has been created. I think I'm misunderstanding something.

Is something wrong with the image below? like, I'm looking at a wrong directory, or....

Would removing that instead work?

Am I misunderstanding this, or verification steps have some mistakes(#154986 (comment))

Ah, a linker script has been created as on Linux when I ran ./x dist rustc. But it seems that macos(ld64) does not recognize linker scripts so I think it's a bit weird to place a file which does not work fine on the platform

Upstream LLVM was also looking into the default name for macos: https://github.com/llvm/llvm-project/
pull/189004 and llvm/llvm-project#188963

**LLVM_VERSIONED_DYLIB_NAME_ON_DARWIN**:BOOL
  Defaults to ``ON``. If set to ``ON``, Darwin shared libraries built through
  LLVM's CMake helpers use versioned dylib filenames and install names, matching
  the behavior on other Unix platforms more closely. If set to ``OFF``, Darwin
  keeps the legacy unversioned dylib install name, for compatibility with
  existing consumers that expect ``@rpath/libLLVM.dylib``.

It seems like that got rid of the extra handling on the llvm side, so we could subsequently drop it as well. The next release is 3 months out. Maybe we could backport it in two steps, first having it disabled, and then (as part of this PR) enabling it? I'd at least try to avoid first spending time on one solution here, and then having to update it again in 3 months, as each change has the risk of breaking users.